Large-scale, complex computer systems are brought into use through integration of software programs with a hardware platform. In many cases these large-scale systems require multiple configurations of software depending on the particular installation. Additionally, many of these systems are real-time in nature, where the speed and, more importantly, the predictability of the system's performance is key. Lastly, many systems are "servers" which means that they are expected to run continuously for long periods of time without interruption.
A telecommunication network is an example of such a complex system. Telecommunication networks facilitate communications between a large number of public and private communications systems by providing numerous functions such as switching, accounting, and time management. A telecommunications network provides these functions through network switches, or nodes, interconnected by links, or channels, of transmission media such as wire, fiber-optic cable, or radio waves. Some of the nodes are connected to one or more users.
Modern telecommunication networks require complex, automated switching and, to that end, software programs are written to provide dependable performance and efficient use of resources, along with implementing service features and functions, such as Call Waiting, Caller ID, and the like. In such systems there may be different configurations depending on what types of transmission media are used, what types of users are served, and what mix of features are purchased. In order to perform dependably, all software required for operation must be loaded into the system and initialized before the system begins its normal processing; otherwise, unpredictable variations in performance, and even unacceptable delays, might be experienced as needed software is identified, loaded, and initialized before processing can continue.
A computer language for implementing software for such systems is "Java." Java was introduced by Sun Microsystems, Inc., of Palo Alto, Calif., and has been described as an object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, and dynamic computer language. A key feature of Java with respect to this invention is its ability to load software dynamically. In many programming systems today, entire software applications are constructed (i.e., software modules are linked together) as a unit. Java, however, allows software modules to be loaded and linked into a running program environment, known as a Java virtual machine (JVM). Thus, changing one module need not involve re-linking the entire application. Furthermore, applications may be extended by adding modules to the application without interrupting execution of the application. This capability makes Java very useful in the construction of server software applications.
In the Java programming language, individual source files describing classes are compiled to produce class files, which are the most basic unit of software introduced into a system. As used herein, the term "class" refers to a generalized category that describes a group of more specific methods that can exist within it, and are comparable in concept to the types of "pigeonholes" used to organize information. The term "method" as used herein denotes a procedure or a function. Data and methods, taken together, generally serve to define the contents and capabilities of an object.
Classes may be grouped into "packages," but packages are not presently a unit by which software code is loaded into a system. In a standard Java virtual machine (JVM), classes are typically loaded one at a time from class files, or perhaps from a compressed archive containing a number of class files within it, possibly from unrelated packages. In accordance with a method of loading often referred to as "lazy loading," a class is not loaded until that class is needed by the JVM. Any necessary initialization for that class is similarly deferred for as long as possible. These techniques are suitable for software systems, such as "applets" in web browsers, that are primarily user-interactive. If all software that might possibly be needed were to be loaded and initialized before the applet could interact with the user, the user would experience an unacceptable delay.
While lazy loading is appropriate for non-real time systems, such as that described above, lazy loading of software applications into the JVM is usually not appropriate for real-time server applications. The unpredictable performance and unexpected latency associated with lazy loading is often intensified because Java classes are commonly dependent on other classes. In many cases, in order to load one class, if other classes upon which the one class depends have not yet been loaded, the JVM will stop loading the one class while it attempts to load the other classes.
In accordance with conventional JVM technology, application software is executed by first loading a "key" class and then executing a particular method of that class. In a stand-alone application, the key class is a class with a "main" method which provides a starting point for the program. In an applet in a browser window, the key class is derived from the base applet class and is loaded, and a "start" method is called. In either the stand-alone application or the applet, once the key class is loaded, the remaining classes are identified and loaded as required. In some cases, security controls are used to constrain class loading. For example, an applet can only load classes from the same server from which the applet itself was initially loaded. The JVM does keep track of classes loaded, but does not keep track of packages loaded, nor does it keep track of certain attributes of classes and packages that might be of interest.
For reasons of manageability, in a large-scale system having at least a single JVM, entire applications may be loaded more efficiently as collections of packages, each of which packages encapsulates a collection of classes. This reduces, by an order of magnitude, the number of software objects that must be managed. Furthermore, if more than one application is loaded into a single JVM of the system, some packages may be shared between the applications and so need only be loaded once, reducing load times and saving memory space. In such a case, the package becomes the unit of software loaded into the system, rather than the individual class file. It thus becomes more important to ensure that the package, as a concrete unit of software, can be immediately loaded from a package load file that contains all classes belonging to the package.
Another feature of large-scale systems is that some software objects that make up the configuration of a running system may not have been developed, tested, and packaged at the same time. Instead, the objects may be of different vintages, and include some components that have remained unchanged for a long time, and some other components that continually change as the software is further developed and improved. As a result, it is often important to know what software objects are loaded into such a system, and to be able to ensure that only objects of compatible vintages are combined together.
Accordingly, a continuing search has been directed to the development of methods for loading classes without incurring unpredictable performance and unexpected latency associated with lazy loading, for loading packages only as needed to avoid increased load times and depleting memory unnecessarily, and for ensuring that software objects loaded in a system are of compatible vintages.